The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session, giving rise to a new generation of personalised, rich multimedia communication services.
FIG. 1 illustrates schematically how the IMS 2 fits into the mobile network architecture in the case of a GPRS/PS access network. The IMS 2 includes a core network 2a and a service network 2b. Call/Session Control Functions (CSCFs) 4 operate as SIP proxies within the IMS 2. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF. In addition the IMS network includes a Home Subscriber Server (HSS) 6. The HSS 6 is the master user database that supports the IMS network entities. It contains subscription-related information and credentials for further authentication and authorisation of users.
A user registers with the IMS using the specified Session Initiation Protocol (SIP) REGISTER method. This is a mechanism for attaching to the IMS and announcing to the IMS the address at which a SIP user identity can be reached. The user receives a unique URI (Uniform Resource Indicator) from the S-CSCF for it to use when it initiates a dialog. In 3GPP, when a SIP terminal performs a registration, the IMS authenticates the user, and allocates an S-CSCF to that user from the set of available S-CSCFs. When a registered user subsequently sends a session request (e.g. SIP INVITE) to the IMS, the request will include the P-CSCF and S-CSCF URIs so that the P-CSCF is able to forward the request to the selected S-CSCF. The registration information is stored by the HSS for a duration, which may be a set time before the end of which the user must re-register or until the user de-registers.
As specified in the 3GPP Technical Specification TS24.229 a user terminal (UE) can register a contact address for any IP address that it has acquired. This is particularly useful when the UE registers with the IMS over different access networks from which it acquires different IP addresses. As a result, the S-CSCF will have multiple contact addresses registered for the UE, each including the combination of the UE's IMS Private User Identity (IMPI) and IMS Public User Identity (IMPU). In addition a UE can register multiple contact addresses by including several contact address headers with different contact header parameters (but keeping the same IP address and port). For example, the different header parameters may be different feature tags. Multiple contact addresses also arise as a result of the S-CSCF generating permanent and temporary Globally Routable User Agent URIs (GRUUs). As a result of the above there are many situations where an S-CSCF will have registered more than one contact address for the IMPI/IMPU combination of a UE.
The present invention is concerned with resolving problems that can arise following a failure of a S-CSCF node, and the subsequent restoration of IMS services. Currently 3GPP is standardising the procedures for restoration of IMS services and TS 23.380 has been written for this purpose, with the intention of resolving registration state inconsistencies in the network and restoring the service for the end user after failure of the S-CSCF node. However, there are currently problems that can arise where multiple contacts are registered for a UE, and these are discussed in more detail below. These problems will be better understood by first considering how a UE successfully registers multiple contact addresses.
FIG. 2 illustrates the signal flows between network entities, for a UE 20 successfully registering an initial contact address, Contact1, for the combination IMPI1/IMPU1. The network entities include, a P-CSCF 22, an I-CSCF 24, the user's HSS 28 and a S-CSCF 26. To start with the S-CSCF has no record of any contact addresses registered for the IMPI1/IMPU1 combination, a situation that could arise before the user has requested any contact address registrations, or if the S-CSCF 26 has lost registration data (e.g. following a restart after a failure).
At step 201 the UE 20 initiates the registration of a contact address (Contact1) by sending a registration request to the IMS network via the P-CSCF 22. This is forwarded at step 202 to the I-CSCF 24. At step 203 the I-CSCF 24 sends a User Authorisation Request (UAR) to the HSS 28, which contains an indication that “REGISTRATION” is requested for the IMPI1/IMPU1 combination. At step 204 (assuming that the user is authorised) the HSS 28 returns a User Authorisation Answer (UAA) to the I-CSCF 24 with the indication that this is a “FIRST_REGISTRATION” and defining the capabilities required of the S-CSCF that will be assigned for this purpose. The I-CSCF assigns (not shown) S-CSCF1 having the required capabilities. At step 205, the I-CSCF 24 forwards the registration request to the S-CSCF1 26.
At step 206 the S-CSCF1 26 sends a Server Assignment Request (SAR) message to the HSS 28 with the indication “REGISTRATION” together with the Contact1 address information that the S-CSCF1 26 uses. At step 207 the HSS stores the information provided by the S-CSCF1 26 for the purpose of backing up this information in case this is required for subsequent restoration. At step 208 the HSS 28 returns a Server Assignment Answer (SAA) to indicate that the process has been successfully completed (DIAMETER_SUCCESS). This also includes the data that has been backed-up, and ensures that the S-CSCF1 26 now has all the information it requires, including the user profile and the IMPIs registered with IMPU1. Steps 209 to 211 are 200 OK messages past back through the network to the UE 20 to indicate that the registration of contact1 has been successfully completed.
FIG. 3 illustrates the signal flows between the network entities for the UE 20 successfully registering a second contact address, Contact2, for the combination IMPI1/IMPU1, which has already been registered with Contact1.
As shown in FIG. 3, at step 301 the UE 20 initiates registration the Contact2 address. The process proceeds through steps 302 to 305 in the same way as steps 202 to 205 described above in FIG. 2 for the registration of Contact1. At step 306, the S-CSCF1 26 sends a SAR to the HSS 28, but this is a re-registration message, and includes the details of all the S-CSCF information to be backed up by the HSS, and including both the already existing contact address information for Contact1, as well as the new contact address information for Contact2. At step 307, although the HSS 28 already has S-CSCF restoration information backed up for the IMPI1/IMPU1 combination with Contact1, because the SAR indicates a re-registration this information is overwritten by the HSS 28 with the updated information in the SAR. Once this information has been backed up by the HSS 28 it returns a SAA to the S-CSCF1 26 at step 308, and the process is completed through steps 308 to 311 as described above for the registration of Contact1 in FIG. 2 steps 208-211.
FIG. 4 illustrates a problem that can arise with the current procedures in the event of a failure or re-start of the S-CSCF. As shown in FIG. 4 at step 400 a failure (crash) has occurred to the S-CSCF1 26 such that all the user information has been cleared. The failure has been restored, either by re-starting S-CSCF1 26 or by the I-CSCF 24 assigning another S-CSCF. However, the S-CSCF 26 has no data relating to registration of the Contact1 or Contact 2 addresses. Although this data was backed up by the user's HSS 28, the S-CSCF 26 has no way of knowing which users were previously registered, or to which networks they subscribed, so it cannot yet obtain the restoration data from the HSS 28.
At step 401 the UE 20 attempts to refresh the registration of Contact1. This may occur, for example, because the UE knows that the registration of Contact1 is about to be timed out and that it is necessary to refresh the registration. At step 402 the request is forwarded from the P-CSCF 22 to the I-CSCF 24 and at step 403 the UAR is sent to the HSS 28, as described above. At step 404 the HSS 28 returns a UAA, as before, to provide to the I-CSCF 24 the requirements of the S-CSCF 26. As in the initial registration shown in FIG. 2, the I-CSCF 24 assigns an S-CSCF 26 (which could be S-CSCF1 or another S-CSCF that has been newly selected to replace S-CSCF1). At step 405 the I-CSCF 24 forwards the registration request information to the appropriate S-CSCF 26. However, because the S-CSCF 26 has no data stored in it in relating to the IMPI1/IMPU1 combination, it will assume that this is a new registration request. Therefore, at step 406 the S-CSCF sends a SAR including the Contact1 information to the HSS 28. At step 407, the HSS 28, receiving the SAR with the Contact1 information from the S-CSCF 26 simply, as before, overwrites any existing information it has and at steps 408 through to 411 the “successful” registration of contact1 is indicated by the signals fed back to the S-CSCF 26 and to the UE 20. This means that, as step 407, the previously backed-up information regarding the Contact2 registration has been lost.
FIG. 5 illustrates another problem that can arise with the current procedures in the event of a failure or re-start of the S-CSCF 26. As in FIG. 4, at step 500 a failure (crash) has occurred to the S-CSCF1 26 such that all the user information has been cleared. The failure has been restored, either by re-starting S-CSCF1 26 or by the I-CSCF 24 assigning another S-CSCF. However, the S-CSCF has no data relating to registration of the Contact1 or Contact 2 addresses. In this instance, at step 501, the UE initiates a de-registration of the Contact1 address.
At step 502 the de-registration request is forwarded from the P-CSCF 22 to the I-CSCF 24 and steps 503 to 505 proceed as described above in steps 403-405 of FIG. 4. Again, as above, the S-CSCF 26 on receiving the de-registration request has no data stored in its memory in relation to the user. According to current procedures, the S-CSCF simply forwards a SAR message to the HSS, but this will indicate that the S-CSCF information is empty, or simply including no S-CSCF information. Thus, at step 507, the HSS overwrites its backed-up data in relation to the registration of contact addresses for the UE 20 resulting in this data being cleared. As a consequence, the user of UE 20 is now de-registered from the IMS, although all it wished to do was to de-register the Contact1 address. As before, at steps 508 to 511 the “successful” de-registration is communicated back to the UE 20.
The present invention has been conceived with the foregoing in mind.